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MIGRATION DE DIFFERENTS LANGAGES SOURCES VERS UN SUPPORT DEXECUTION. 

^invention execute automatiquement dans un unique 
support d'execution plusieurs programmes (P1, PN) ecrits 
en des langages sources (LSI , LSN) auxquels des supports 
tf execution respectifs (SE1, SEN) sont dedies, sans con- 
traindre un programmeur a un langage source unique pour 
un type de support d'execution respectif. Chaque progranv 
me est compile (E1 , E2; E12) en un programme exprime en 
un langage intermediaire (LI) representatif tfun sous-en- 
semble minimal des langages sources. Dans un moyen de 
traitement de donnees tel qu'une carte a puce (CU; CS), un 
support d'execution (SEU; SES) est dedie au langage inter- 
mediaire. Le programme en langage intermediaire est char- 
ge avec une bibliotheque de programmation respective 
(BPn) adaptant le langage source respectif au langage in- 
termediaire afin d'executer le programme en langage inter- 
mediaire dans le support cf execution (SEU; SES). 
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Migration de differents langages sources vers un 
support d' execution 

L 1 invention concerne les cartes a puce, dites 
5 egalement cartes a microprocesseur, et plus 
generalenient des moyens de traitement de donnees 
ouverts programmables a microprocesseur pouvant etre 
charges par des applications ecrites dans des 
langages de prograiranation evolues. 

10 L 1 invention est plus particulierement dirigee 

vers 1 'heterogeneite de ces differents langages qui 
ne permet pas d'ecrire une application dans un 
langage particulier et de la faire executer par 
n'importe quel moyen de traitement de donnees 

15 programmable ; 1' invention est par consequent dirigee 
egalement vers l'ouverture de. moyens de traitement de 
donnees. ^'invention concerne 1 ' interoperability 
d f applications ecrites pour des moyens de traitement 
de donnees programmables, telles que JAVA Card, 

20 WINDOWS for SMART Card, MultOS (marque deposee) , etc. 
L' interoperability est assortie d' exigences en terme 
de securite. 

Dans le domaine des cartes a puce programmables, 
25 chaque langage source de prograiranation utilise pour 
§crire une application destinee a' etre chargee dans 
une carte est fortement lie a un support d f execution 
particulier general ement ayant un caractere logiciel, 
comme une machine virtuelie, mais aussi ayant un 
30 caractere materiel, comme un microprocesseur. 

Pour pouvoir charger un programme dans une carte 
a puce, le programme £crit dans un langage source 
donne est compile, puis est charge dans la carte a 
puce specialement destinee a accueillir des 
35 programmes ecrits dans le langage source donne. La 
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carte regoit le programme compile et 1* execute au 
mo yen d'un support d T execution sp£cialement dedie 3 
1" execution de programmes initialement ecrits dans le 
langage source donne. 

5 Comme montre a la figure 1/ des cartes a puce Cn 

contenant chacune un support d' execution respectif 
SEn differents de ceux SE1 a SEN d'autres cartes a 
puce CI a CN, avec I'entier n compris 1 et un nombre 
entier N grand designant un nombre predetermine de 

10 langages sources LSI a LSN, ne peuvent ex£cuter des 
programmes applicatifs Pn que si elles sont 
programmes dans le langage source respectif LSn. 
Pr6alablement a la compilation du programme a 
charger, celui-ci subit une verification de code pour 

15 controler que le programme a charger n'enfreint pas 
des proprietes de securite fournies par le support 
d F execution SEn associe au langage source LSn. 

En fait dans un tel ensemble de cartes, un 
programme Pn developpe dans un langage source LSn 

20 donne est intimement lie au support d* execution cible 
SEn au motif que : 

1) les structures de donn£es et les operations 
fournies par le langage source LSn sont specialises 
pour etre compil£es vers une representation optimisee 

25 en taille et en vitesse pour le support d' execution 
SEn dedie au langage source LSn ; 

2) des bibliotheques de programmation BPn 
fournies avec le langage source LSn sont en general 
correlees au langage source et optimis6es pour le 

30 support d' execution SEn dedie au langage source ; 

3) la verification du programme Pn avant qu'il 
ne soit charge dans une carte Cn est intimement li£e 
aux proprietes de securite assurees par le support 
d ? execution cible SEn. 
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Cette forte liaison entre un langage source LSn 
et son support d' execution SEn se concretise dans une 
chaine de verification, compilation et chargement 
CVCCn. Cette chaine g£re une transformation d'un 
5 programme Pn ecrit dans un langage source de haut 
niveau en une forme compacte et prete & etre ex6cutee 
de fagon efficace par le support d* execution SEn 
dedie au,. langage source LSn. 

10 Le probleme general a l'origine de l'invention 

est de lier des programmes ecrits avec n'importe 
lequel de differents langages sources LSI a LSN, a 
differents supports d* execution SE1 a SEM, M etant un 
entier quelconque egal ou different de l'entier N. Ce 

15 probleme general peut etre decompose en les trois 
sous-probl&mes suivants. 

Selon le premier sous-probleme SP1, il s'agit, 
par exemple, de faire executer un programme P ecrit 
avec un langage source LSn sur un support d' execution 

20 SEm dedie £ un langage source donne LSm, avec 
1 1 indice m compris entre 1 et M. 

Le deuxieme sous-probleme SP2 consiste a charger 
des programmes PI £ PN ecrits respectivement avec 
differents langages sources LSI a LSN dans un support 

25 d 1 execution commun SEm capable d'apporter a ces 
differents programmes un envirohnement efficace en 
terme de taille memoire, de rapidite d' execution, de 
leurs bibliotheques de programmation BP1 a BPM et de 
leurs proprietes de securite. 

30 Le troisieme sous-probleme SP3 vise a faire 

coexister differents programmes PI & PN Merits 
respectivement en differents langages sources LSI a 
LSN au sein d'un support d 1 execution commun SEm. Pour 
le troisi£me sous-probleme, il est recommande de 

35 traiter la securite des programmes PI £ PN issus de 
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differents environnements de pfograramation et places 
dans sur un meme support physique. 

Pour la resolution des trois sous-problemes SP1, 
SP2 et SP3 qui revient a resoudre 1 ' interoperabilite 

5 de differentes applications ecrites par exemple pour 
des cartes a puce programmables avec conservation de 
la securite et des mecanismes de protection et 
d 1 interaction, l'homme du metier pourrait envisager 
les trois categories de solutions suivantes qui sont 

10 cependant peu satisf aisantes . 

La premiere solution, la plus simple et la plus 
utilisee, consiste & r6ecrire un programme Pn ecrit 
dans un langage source LSn dedie ct un support 

15 d* execution SEn implante dans une carte a puce Cn, en 
des programmes Pnl et PnM ecrits respectivement par 
exemple en des langages sources LSI a LSM dedies & 
des supports d' execution SE1 et SEM implantes dans 
des cartes a puce CI et CM, comme indique par des 

20 operations d'ecriture Wl et WM dans la figure 2. 

La premiere solution presente comme principal 
inconvenient une lourde et fastidieuse t&che prise en 
charge manuellement par un programmeur, consistant en 
la reecriture de l'algorithrae du programme Pn en le 

25 programme Pnl, PnM qui doit etre adaptee aux 
structures de donnees et bibliotheques de 
programmation differentes BP1, BPM pour le nouveau 
langage source LSI, LSM. De plus, les mecanismes de 
securite fournis par chacun des nouveaux supports 

30 d'execution SE1 et SEM necessitent de refaire 
certifier le code du programme reecrit Pnl, PnM. 

La premiere solution ne traite uniquement que le 
sous-probleme SP1 et ainsi ne resout que tres 
partiellement le probleme de 1 1 interoperability de 

35 programmes. De plus, si un autre langage source 
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associe a un support d' execution autre que les 
supports d* execution SE1, SEn et SEM apparait dans 
une nouvelle carte, il faut reprendre tous les 
anciens programmes ecrits dans le langage source 
5 initial LSn pour les reecrire avec ledit autre 
langage source. 

La deuxieme solution comporte une compilation 
croisee. 

10 En reference a la figure 3, soit par exemple 

deux programmes PI et P2 qui sont ecrits en des 
langages sources respectifs LSI et LS2 auxquels sont 
initialement dedies deux supports d 1 execution 
respectifs SE1 et SE2 dans deux cartes a puce CI et 

15 C2 ; apres avoir subi des compilations dans des 
chaines de verification, compilation et chargement 
CVCC1 et CVCC2, ils peuvent etre executes 
classiquement chacun dans les supports d 1 execution 
SE1 et SE2. Toutefois, les programmes PI et P2 

20 doivent etre ex£cut6s dans les supports SE2 et SE1 
respectivement, et egalement tous les deux dans un 
troisieme support d' execution SE3 contenu dans une 
troisieme carte a puce C3 et dedi£ a un troisieme 
langage source LS3 . 

25 Pour ex£cuter le programme PI, ou P2, dans les- 

supports d 1 execution cibles SE2 et SE3, ou SE1 et 
SE3, autre que celui SE1, ou SE2, dedi6 au langage 
source initiale LSI, ou LS2, le programme PI, ou P2, 
subit des compilations dans des chaines 

30 additionnelles de verification, compilation et 
chargement CVCC21 et CVCC31, ou CVCC12 et CVCC32 . 

Comparativement a la premiere solution, la 
deuxi&me solution ne necessite plus de la part d'un 
programmeur de r66crire manuellement les programmes, 

35 mais requiert la mise a disposition de tres 
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nombreuses chaines de verification, compilation et 
chargeinent CVCC12, CVCC21, CVCC31, CVCC32 . Plus 
generalement, pour N langages sources LSI a LSN et M 
supports d'execution SE1 a SEM, N*M chaines de 

5 verification, compilation et chargement sont 
n§cessaires. Ces chaines impliquent par leur nombre 
et leur complexity un investissement materiel, 
logiciel et humain considerable. 

Outre cet inconvenient majeur, la deuxidme 

10 solution presente les inconvenients suivants : 

- mauvaises performances en taille memoire et 
rapidite d' execution des programmes ainsi gen£r§s, 
les supports d f execution dans lesquels ils sont 
executes n'etant pas a priori convenablement adapt£s 

15 aux structures de donnees, operations et 
bibliotheques de programmation des langages sources 
LSI et LS2 utilises pour ecrire ces programmes ; 

realisation de chaines de verification, 
compilation et chargement egal en nombre aux supports 

20 d'execution cibles existants SE1 a SEM lorsqu'un 
nouveau langage source apparait, et reciproquement 
egal en nombre aux langages sources existants LSI & 
LSN lorsqu'un nouveau support d'execution apparait ; 

- pour le d£ploiement des programmes, chargement 
25 prealable de tous les postes de telechargement avec 

les programmes dotes des codes compiles et certifies 
pour les differents supports d'execution SE1 £ SEM, 
ce qui rend la deuxieme solution encore plus complexe 
et couteuse. 

30 La deuxieme solution ne traite uniquement que le . 

sous-probleme SP1 mais de mani&re automatis£e 
comparativement & la premiere solution, et ainsi ne 
r£sout que tres partiellement le probl&me de 
1 ■ interoperabilite. De plus, si un autre langage 

35 source associe & un support d' execution autre que. les 
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supports d' execution SE1 a SEM apparait dans une 
nouvelle carte, il faut passer tous les programmes 
initiaux PI - & PN dans de nouvelles chaines de 
verification, compilation et chargement produisant 
5 des codes certifies pour ledit autre support 
d 1 execution. 

La troisieme solution suggere des cartes a puce 
CP qui contiennent chacune plusieurs supports 

10 d' execution, par exemple trois supports d f execution 
SE1, SE2 et SE3, conune montre ct la figure 4. Ainsi, 
des programmes PI, P2 et P3 ecrits respectivement 
avec des langages sources differents LSI, LS2 et LS3 
peuvent etre charges dans la carte CP a travers des 

15 chaines respectives de verification, compilation et 
chargement CVCC1, CVCC2 et CVCC3. La carte CP apporte 
a chaque programme PI, P2, P3 exactement les memes 
fonctionnalites que s ! il etait charge 

individuellement sur une carte ne comportant que le 

20 support d 1 execution SE1, SE2, SE3 dedie au langage 
source respectif LSI, LS2, LS3. 

La troisieme solution conserve avantageusement a 
l'identique les chaines de verification, compilation 
et chargement CVCC1, CVCC2 et CVCC3 respectivement 

25 associ6es aux langages sources LSI, LS2 et LS3 et 
permet aussi de resoudre le sous-probl£rae SP2. 

Neanmoins, la troisieme solution pr£sente 
. 1 ' inconvenient majeur d*etre actuellement d'autant 
plus irr&alisable que le nombre de supports 

30 d' execution differents a implanter dans la carte et 
representant chacun une quantite importante de code 
est elev£. La m£moire n§cessaire a la troisieme 
solution n'est pas concevable actuellement dans une 
carte d puce et serait en pratique plus utilement 
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exploitable pour memoriser davantage de donnees et de 
programmes par exemple. 

L' object! f principal de 1' invention est de 
5 fournir un procede pour executer automatiquement 
plusieurs programmes Merits dans des langages sources 
differents dans un unique support d 1 execution, sans 
contraindre un programmeur a un langage source unique 
pour un type de support d' execution respectif. Cet 
10 objectif principal revient a resoudre les trois sous- 
problemes definis ci-dessus SP1, SP2 et SP3, e'est-a- 
dire 1 1 interoperabilite des programmes en differents 
langages sources qu'aucune des trois solutions 
presentees ci-dessus ne resoud completement . 

15 

A cette fin, le procede de migration de 
plusieurs programmes Merits respectivement en des 
langages sources auxquels des supports d' execution 
respectifs sont dedies, vers un moyen de traitement 
20 de donnees, est caract£rise en ce qu'il comprend les 
etap.es de : 

- compiler chaque programme en un programme 
respectif exprime en un langage intermediaire 
representatif d'un sous -ensemble minimal des langages 

25 sources, 

- fournir dans le moyen de traitement de donnees 
un support d' execution predetermine dedie au langage 
intermediaire, et 

- charger le programme respectif en langage 
30 intermediaire dans le moyen de traitement de donnees 

avec une bibliotheque de programmation respective 
adaptant le langage source respectif au langage 
intermediaire afin d f executer le programme en langage 
intermediaire dans le support d* execution 
35 predetermine. 
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L 1 invention repose sur la recherche d'un support 
d' execution qui est initialement le plus petit 
denominateur commun present dans des supports 
d f execution de moyens de traiteraent de donnees £ 
5 microprocesseur predetermines ; par exemple les 
supports d' execution sont contenus dans des cartes a 
puce connues de differents types, c'est-a-dire dont 
les programmes sont ecrits en des langages sources 
differents. L' invention off re done les avantages de 
10 la troisieme solution presentee precedemment, 
suggerant de mettre dans un moyen de traitement de 
donnees & microprocesseur l 1 ensemble de tous les 
supports d' execution possibles. Mais au lieu d'exiger 
une taille de memoire considerable, voire 
15 irrealisable, 1' invention n'implante qu'un support 
d 1 execution reduit dedi<§ a un langage intermediaire 
minimal, mais flexible dans chaque moyen de 
traitement de donnees, tel que carte £ puce. En temps 
que tel, le langage intermediaire n'est associe £ 
20 aucun langage source particulier, et sert de langage 
de base pour servir de cible a plusieurs langages 
sources. La memoire requise pour implanter le langage 
intermediaire est ainsi reduite et par consequent 
1' execution d'un programme est plus rapide que dans 
25 la troisieme solution suggeree ci-dessus. 

L' invention met ainsi en oeuvre la combinaison : 
d'un langage intermediaire capable de 
representer aussi bien les programmes issus de 
differents langages que les bibliotheques de 
30 programmation et les proprietes de securite 
specifiques necessaires a leur bon fonctionnement, et 
- d'un support d* execution dedie au langage 
intermediaire, mais capable d'etre reconfigure pour 
s' adapter au mieux aux exigences de chaque langage 
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aussi hi en en terme d' environnement de travail qu'en 
terme de contrdle de s6curite des applications. 

Selon une variante de 1* invention, l'etape de 
5 compiler peut comprendre les etapes de : 

- compiler le programme en un programme compile 
en un langage machine auquel le support d' execution 
respectif est dedie, et 

- convertir le programme compile en le programme 
10 respectif exprime en langage intermediaire. 

Cette variante peut £tre. d'interet pour un 
developpeur de programme a partir du resultat compile 
d'un programme pour produire le code en langage 
intermediaire. L'outil qui permet cette operation est 

15 un convertisseur . II remplace les instructions du 
support d' execution respectif associe au langage 
source par des operations ecrites en langage 
intermediaire. 

Selon un autre aspect de l 1 invention, le proc£d£ 

20 peut comprendre une etape, avant l'etape de charger, 
pour extraire des informations de validation du 
programme respectif en langage intermediaire, et une 
etape, apres l'etape de charger, pour verifier les 
informations de validation extraites dans le support 

25 d ? ex6cution predetermine. 

Selon une autre variante, le support d' execution 
s predetermine peut etre analogue 3 l'un des supports 

d ? execution. Bien que globalement moins avantageuse 
30 que la realisation de base de 1" invention, cette 

variante peut etre int£ressante lorsque les langages 

sources sont des langages ayant subis des evolutions 

et modifications analogues. 
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De preference/ le langage intermediaire est 
extensible, tandis que le support d* execution 
predetermine est extensible ou non extensible. Au 
moins l'un des langages sources et le langage 
5 intermediaire sont avantageusement des langages 
orientes objet. 

En pratique, le procede peut comprendre une 
etape de lire des caracteristiques du support 
d f execution predetermine par un serveur qui ensuite 
10 effectue 1' etape de compiler. 

Le moyen de traitement de donnees est par 
exemple une carte £ puce. La carte & puce peut etre 
une carte d'identite d'abonne incluse dans un 
terminal radiotelephonique mobile. 

15 

D'autres caracteristiques et avantages de la 
pr&sente invention apparaitront plus clairement a la 
lecture de la description suivante de plusieurs 
realisations pr£ferees de 1' invention en reference 

20 aux dessins annexes correspondants dans lesquels : 

- la figure 1 deja commentee est un diagramme de 
production et d' execution de plusieurs programmes 
respectivement ecrits en des langages sources 
differents pour des supports d' execution respectifs ; 

25 - les figures 2, 3 et 4 dej& commentees sont des 

diagrammes de premiere, deuxieme et troisieme 
solutions partielles a 1 1 interoperability de 
programmes en langages sources differents, suggerees 
par la technique anterieure, respectivement ; 

30 - la figure 5 est un diagramme de prpduction et 

d' execution de plusieurs programmes ecrits en des 
langages sources differents pour etre executes dans 
un support d* execution dedie & un langage 
intermediaire et contenu dans une carte & 
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microprocesseur, selon une realisation pr6fer£e de 
1' invention et des variantes de celle-ci ; 

- la figure 6 montre des etapes de compilation 
et conversion d'un programme 6crit en un langage 

5 connu, en un langage intermediate selon 1* invention; 

- la figure 7 est une etape de compilation d'un 
programme 6crit en un langage connu, analogue au 
programme de la figure 6, directement en langage 
intermediate ; 

10 - la figure 8 montre une etape d' adaptation 

d'une sequence en langage intermediaire avant 
execution selon la premiere realisation ; 

- les figures 9 et 10 montrent des conversions 
d'une sequence ecrite en un langage de machine 

15 virtuelle en des sequences sans et avec extension du 
langage intermediaire, respectivement ; et 

- la figure. 11 montre une adaptation d'une 
sequence en langage intermediaire avant execution, 
selon une variante de 1' invention. 

20 

En reference £ la figure 5, N programmes 
applicatifs PI a PN sont susceptibles d'etre Merits 
respectivement en des langages sources LSI a LSN a 
priori differents dans un serveur d' application SER . 

25 Les langages sources sont parfois appeles "langages 
evolu6s" ou "langages de haut niveau". 

Selon une realisation prefer£e de 1' invention, 
le procede de migration a pour object if de faire 
migrer n' importe lequel programme Pn ecrit dans le 

30 langage source respectif. LSn vers un support 
d' execution universel SEU selon 1* invention, contenu 
dans un moyen de traitement de donn^es correspondant, 
tel qu'une carte a puce programmable "universelle" 
CU, comme defini ci-apr£s. 
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Comme illustrS & gauche dans la figure 5, le 
proc£de de migration comprend essentiellement quatre 
etapes El a E4, apres une etape initiale de 
d£veloppement et de fourniture EO d'un programme Pn 

5 dans le langage source respectif LSn, avec 1 < n £ N. 

Les programmes PI a PN ont et£ d£velopp£s dans 
un serveur SER relie a un terminal TE contenant la 
carte CU & travers un rSseau de telecommunications 
RES. Par exemple, le terminal TE est un terminal 

10 bancaire relie au serveur par des lignes loupes ou 
sp£cialisees du reseau RES ; selon un autre exemple, 
le terminal TE est un terminal radiotel£phonique 
mobile de type GSM relie au serveur SER par un reseau 
de radiotel6phonie cellulaire numerique RES, le 

15 serveur etant reli£ h des commutateurs du service 
mobile (MSC) a travers le reseau de signalisation du 
reseau de radiotelephonie, et la carte CU etant une 
carte d'identite d'abonne de type SIM (Subscriber 
Identity Module) amovible du terminal TE. 

20 

A 1 'etape El, le serveur SER interroge le 
support d* execution SEU dans la carte CU de maniere a 
y lire et enregistrer des caracteristiques deja 
pr£sentes du support d' execution. Puis le programme 

25 Pn en langage source LSn est compile en un programme 
compile PCn exprim6 en un langage machine auquel est 
. dedi§ le support d' execution cible respectif SEn. Un 
compilateur realisant l'etape El est un programme 
installe dans le serveur SER. Puis a l'etape E2, le 

30 programme compile PCn est converti en un langage 
intermediaire LI selon 1' invention. Comme le 
compilateur, un convertisseur de langage est un 
programme implements dans le serveur SER et realise 
l'etape E2 . 
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Le langage intermediaire LI possede notamment 
les deux proprieties suivantes : 

- extensibility : le langage LI est capable 
d'enrichir le champ de commandes elementaires pour 
5 exprimer ef f icacement des programmes issus d'autres 
langages ; 

typage fort : comme il est connu, les 
mecanismes de s£curit£ du code par typage constituent 
le grain le plus fin possible pour un controle de 

10 s^curite ; les proprietes de security de chaque 
langage sont alors sp6cifi6es a partir du modele 
initial present dans la carte ; le langage 
intermediaire LI permet un controle par typage 
extensible a la maniere des types ou des classes des 

15 langages a objet. 

Le langage intermediaire LI ne contient qu'un 
nombre tres limite d 1 instructions constituant un 
sous-ensemble minimal repr£sentatif des langages 
machines des differents supports d' execution SE1 a 

20 SEN. Une bibliotheque de programmation addi tionnelle 
est utilisee par le convertisseur de langage a 
1'etape E2 pour eviter que chaque operation 
elementaire pour le systeme d' execution SEn ne soit 
remplacee par un ensemble d* instructions pour le 

25 support d' execution universel SEU. Cette precaution 
limite les risques d f augmentation du volume en 
memoire des programmes charges dans la carte CU. 

La figure 6 montre selon un premier exemple les 
30 etapes El et E2 pour un programme en langage source, 
tel qu'un segment de code PJ exprim§ dans le langage 
source oriente objet JAVA relatif a une reception 
dans la carte d'un message transmis par le serveur 
SER. 
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L'etape El effectue classiquement la compilation 
du segment PJ en un programme binaire compile PJC 
sous un format appele pseudo-code (Byte Code) qui est 
capable de fonctionner sous un support d' execution 

5 SEJ, c'est-a-dire un micro-ordinateur ayant 
implements le concept de la machine virtuelle JAVA. 
Classiquement, chaque instruction sous le langage 
JAVA donne naissance a plusieurs instructions du 
langage de la machine virtuelle. 

10 Puis a l'etape E2, le mecanisme de la conversion 

ne se limite pas a une substitution instruction par 
instruction des pseudo-codes JAVA par des pseudo- 
codes du langage intermediaire LI, mais convertit une 
succession d'operations elementaires dans le 

15 programme compile PJC en une sequence differente PJLI 
en langage intermediaire, en determinant des 
arguments d'appels de fonctions par exemple. Cette 
conversion etant effectuee k l'exterieur de la carte 
CU, il est possible d'implanter des techniques 

20 d' optimisation et de transformation utilisees dans 
les compilateurs . La conversion a l'etape E2 garantit 
I'efficacite du code en langage LI transmis a la 
carte, quel que soit le langage source utilise. De 
plus, la conversion de langage contribue £ produire 

25 des elements de preuve du bon fonctionnement du 
langage LI que la carte CU utilise pour controler la 
viabilite du programme ; a 1' issue de l'etape E2, le 
convertisseur de langage fournit des informations de 
typage utiles a la carte pour verifier la viabilite 

30 du programme. 

Selon un deuxieme exemple, la figure 7 montre un 
segment de code PC exprime dans le langage C et 
correspondant a une declaration d'un tableau . de 
travail, comme pour le segment de code PJ en langage 

35 JAVA montre a la figure 6. Apres l'etape de 
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compilation El pour compiler classiquement le segment 
PC destine a un support d' execution dedie au langage 
machine pouvant ex6cuter un programme en langage C, 
1' etape E2 cohvertit le segment correspondant en 

5 langage machine en une sequence PCLI exprimee dans le 
langage intermediaire LI. 

En langage intermediaire LI, la sequence PCLI 
est identique a la sequence PJLI : elles comprennent 
les memes variables et constantes ainsi que des 

JO commandes et operations exprimees de la m§me mani£re, 
except e l'ecriture du declenchement d'une exception 
en fin de sequence propre au langage source initial. 

Le langage intermediaire LI selon l 1 invention 
est ainsi adaptable. Toute operation ou commande 

15 selon les exemples montres aux. figures 6 et 7 est 
exprimee sous la forme d r un message applique a un 
objet. Comme pour un langage connu oriente objet, de 
nouveaux messages dans le langage intermediaire 
peuvent etre definis a tout moment. 

20 

La figure 5 montre une deuxieme variante de la 
premiere realisation, illustree en haut et a droite 
en trait pointille, relative par exemple £ la 
production du programme PN initialement exprime dans 

25 un langage source LSN. Pour cette deuxieme variante, 
les etapes de compilation et conversion El et E2 sont 
remplacees par une etape de compilation E12 qui 
compile le programme PN en langage source LSN en un 
programme compile directement exprime dans le langage 

30 intermediaire LI qui est ensuite verifie et charge 
dans la carte a puce CU a 1' etape E3. 

Selon 1' exemple montre a la figure 7, 1' etape 
E12 convertit directement le segment PC en langage C 
en la sequence PCLI en langage LI . 

35 
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Ensuite, en revenant a l'etape E3 dans la figure 
5, le programme exprime en langage intermediaire LI 
suit une chaine de verification et chargement CVC 
afin qu'il soit verifi6 et teiecharge dans la carte & 

5 puce cible CU. La chaine CVC est au moins en partie 
et de preference totalement installee dans la carte. 
CU. L f autre partie de la chaine CVC concerne 
notamment la verification dynamique de 1" execution du 
programme en langage intermediaire et est installee 

10 soit dans le serveur SER, soit dans un terminal TE 
recevant la carte. 

Un mecanisme de verification et/ou d 1 adaptation 
dans la carte CU a l'etape E3 transforme le code regu 
dans la carte et exprime en langage intermediaire LI 

15 sous la forme d'un programme binaire directement 
executable dans le langage intermediaire. Des 
informations de validite du programme en langage 
intermediaire, relatives notamment a la securite, au 
typage et au confinement, peuvent etre extraites du 

20 programme et etablies dans le terminal TE lors de 
1'etape E3 et verifiees par la carte apres le 
chargement du programme dans la carte. Si la 
verification echoue, le programme est invalide. Cette 
verification assure l'efficacite de 1 ' environnement 

25 dans lequel le programme est utilise, en accord avec 
le sous-probleme SP2. 

Les transformations effectuees lors du 
chargement £ I'etape E3 peuvent etre minimes et etre 
reduites a un mecanisme d 1 edition de lien propre au 

30 milieu des cartes £ puce. 

L'etape E3 a pour but de completer in situ dans 
la carte, le travail effectue aux etapes El et E2, ou 
£ l'etape E12. Le mecanisme de verification et/ou 
d'adaptation convertit completement le code recu et 

35 le transforme en un programme executable par le 
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support cT execution universel SEU dans la carte. 
Cette conversion a pour but de rendre le code plus 
efficace en le soumettant statiquement & des 
controles de securite qui, - lorsqu 1 ils sont executes 

5 dynamiquement, pSnalisent fortement le temps 
d' execution des programmes. En pratique, le m£canisme 
d' adaptation embarque dans la carte CU peut effectuer 
un travail important qui engendre un programme 
directement execute par le support d' execution SEU, 

10 c'est-a-dire le microprocesseur present dans la 
carte. La figure 8 illustre un exemple du traitement 
effectu£ par le m6canisme d 1 adaptation a l'etape E3 a 
partir d'une sequence en langage intermediaire PLI, 
analogue a la sequence PJLI, PCLI pour fournir une 

15 sequence adapt ee PAD. 

A I'etape E4, le programme en langage 
intermediaire LI est installe dans la carte CU qui 
est destin6e a supporter directement le langage 

20 intermediaire LI. La carte SU possede un mecanisme 
d 1 adaptation specif ique. 

La carte a puce CU qui est programmable, c'est- 
a-dire qui accueille des programmes tout au long de 
son cycle de vie, contient le support d'ex^cution SEU 

25 dedi£ au langage intermediaire LI. Ainsi les 
programmes. PI a PN Merits dans les divers langages 
sources LSI a LSN coexistent au sein de la meme carte 
CU qui n'est pas specif iquement dedi6e & l r un des 
langages sources LSI a LSN, mais qui est capable 

30 d'heberger differents programmes 6crits dans 
differents langages sources, ce qui resout le sous- 
probleme SP2 . 

Le support d'execution universel SEU ne contient 
qu'un sous-ensemble restreint des supports 

35 d 1 execution SE1 a SEN des programmes initiaux PI a 
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PN. L'etape E3 charge des bibliotheques de 
progranunation BPn en meme temps que chaque programme 
en le langage intermediaire LI afin d' adapter a 
l'etape E4 le langage source LSn au langage 

5 intermediaire et ainsi executer le programme initial 
Pn dans le langage intermediaire. Des propri£tes de 
securite specif iques au langage intermediaire sont 
importees "par dessus" celles existantes dans le 
support d ? execution universel SEU. L' architecture du 

10 support d' execution universel SEU dans la carte CU 
considere cet aspect pour fournir aux programmes 
heberg&s un environnement efficace en taille m£moire 
et rapidite d 1 execution tout en maintenant les 
propriet^s de securit6, ce qui resout le sous- 

15 probleme SP3. 

Le support d' execution universel SEU place dans 
la carte CU et supportant l f execution du langage 
intermediaire LI est : 

adaptable pour accepter de nouvelles 

20 bibliotheques de progranunation pour chaque nouveau 
langage source supporte afin d'executer le programme 
initialement ecrit dans le nouveau langage dans son 
environnement logiciel ; 

- sOr pour supporter les mecanismes de s^curite 

25 par controle des types manipules par les programmes ; 
et egalement pour accepter la definition de nouveaux 
types afin de decrire des mecanismes de s^curite 
associes lors du chargement de nouvelles 
bibliotheques de programmation. 

30 

A l'etape E4, le mecanisme d 1 interpretation 
avance de programme concerne le support d' execution 
lui-meme. Le support d' execution SEU logiciel et/ou 
materiel est utilise, comme cible pour la generation 
35 de chaque programme executable, pour repondre aux 
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preoccupations des sous-problemes SP2 et SP3. De 
preference, le support d' execution SEU comprend un 
jeu d' instructions different de celui qu'il exploite 
initialement . Cette fonction permet dans l'absolu de 

5 redefinir completement le support d' execution 
universel SEU pour qu'il. puisse directement 
interpreter le code issu d'un langage particulier. Le 
mecanisme d'extension vise & l'etape E4 favorise .par 
exemple des portions de code issues d'un langage 

10 donne et permet surtout d'implanter des operations 
qui definissent une semantique differente de celle 
fournie par le support d' execution universel SEU 
initial de la carte CU. 

Le mecanisme d ? extension est relatif par exemple 

)5 a une instruction el£mentaire d'acc&s a un tableau, 
qui en langage JAVA declenche une exception 
lorsqu'elle sort des limites du tableau, alors que 
dans 1 1 implantation initiale du langage intermediaire 
LI, 1 ' instruction elementaire donne acces a une case 

20 quelconque du tableau. Une solution simple consiste a 
transformer une operation OP J en langage JAVA pour 
acceder & un tableau en une sequence d T operations 
OPLIa en langage intermediaire LI, sans extension de 
celui-ci, comme montre a la figure 9. Pour eviter ce 

25 grossissement inutile du code et penalisant dans la 
carte, une instruction elementaire qui realise 
exactement la semantique equivalente au pseudo-code 
(Byte Code) JAVA est definie dans le support 
d 1 execution universel SEU, comme montre aux lignes 7 

30 a 10 dans une sequence d 1 operations OPLIb & la figure 
10. 

Selon une variante de 1 ? invention, les etapes E3 
et E4 sont remplacees par des etapes. E3d et E4d 
35 montrees a droite de la figure 5. La cible visee est 
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un support cT execution specialise SES ayant . par 
exemple une architecture raaterielle et le cas echeant 
logicielle connue analogue a I'un des supports 
cT execution initiaux SE1 a SEN dedies au langage 

5 source LSI a LSN. 

A l'etape E3d, une chaine.de verification et de 
chargement CVCd est enrichie d'un mecanisrae 
d' optimisation OPT qui g£n£re un code final natif 
efficace qui est optimal a l'exterieur de la carte. 

10 Les contraintes de securite sont de preference 
relachees puisque les programmes sont produits pour 
des cartes a puce specifiques CS une fois pour toute 
et passent par des controles de fiabilite connus du 
secteur industriel. 

15 La figure 11 montre une adaptation a l'etape E3d 

entre une sequence PCId en langage intermediaire LI 
en une sequence adaptee PAd. 

A l'etape E4d, un ensemble de bibliotheques de 
programmation BPn, BPdn sont portees par le support 

20 d' execution SES pour que le programme issu du 
programme Pn en langage source LSn fonctionne dans 
son environnement . 

Le support d' execution SES selon cette variante 
necessite la realisation de M chaines de verification 

25 et chargement, et done I'ecriture d'une nouvelle 
chaine CVC fonction d'un nouveau langage. 

Cette variante est moins avantageuse que la 
realisation avec support d' execution "universel" SEU. 
Le support d' execution SES demeure tributaire d'un 

30 support d' execution predetermine SEn, et 
1 • inadequation entre la bibliotheque de programmation 
BPn du langage source LSn et celle attendue pour le 
support d' execution SES programmee a l'origine pour 
un autre langage requiert une capacite de memoire 

35 plus elevee et conduit a moins d' ef f icacite. 
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RE VEN D I CAT I ON S 

1 - Procede de migration de plusieurs programmes 
(PI a PN) ecrits respectivement en des langages 

5 sources (LSI a LSN) auxquels des supports d' execution 
respectifs (SE1 a SEN) sont dedies, vers un moyen de 
traitement de donnees, caracterise eri ce qu'il 
comprend les etapes de : 

- compiler (El, E2 ; E12) chaque programme (Pn) 
10 en un programme respectif exprime en un langage 

intermediaire (LI) representatif d'un sous-ensemble 
minimal des langages sources, 

- fournir (E4) dans le moyen .de traitement de 
donnees (CU ; CS) un support d' execution predetermine 

15 (SELF ; SES) dedi£ au langage intermediaire, et 

- charger (E3) le programme respectif en langage 
intermediaire dans le moyen de traitement de donnees 
avec une bibliotheque de programmation respective 
(BPn) adaptant le langage source respectif (LSn) au 

20 langage intermediaire (LI) afin d'executer le 
programme en langage intermediaire dans le support 
d' execution predetermine (SEU ; SES) . 

2 - Procede conforme a la revendication 1, dans 
25 lequel l'etape de compiler comprend des etapes de : 

- compiler le programme (Pn) en un programme 
compile (PCn) en un langage machine auquel le support 
d 1 execution respectif (SEn) est dedie, et 

- convertir (E2) le programme compile (PCn) en 
30 le programme respectif exprime en langage 

intermediaire (LI) . 

3 - Procede conforme a la revendication 1 ou 2, 
comprenant une e'tape, avant I'etape de charger (E3) , 

35 pour extraire des informations de validation du 
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programme respectif en langage intermediaife (LI), et 
une etape (E3) , apr&s 1' etape de charger, pour 
. verifier les informations de validation extraites 
dans le support d'execution predetermine (SEU, SES). 

5 

4 - Procede conforme a l'une quelconque des 
revendications 1 a 3, dans lequel le support 
d' execution predetermine (SES) est analogue a 1'un 
des supports d' execution (SE1 a SEN). 

10 

5 - Proced6 conforme a l'une quelconque des 
revendications 1 a 4, comprenant une etape de lire 
des caracteristiques du support d' execution 
predetermine (SEU; SES) par un serveur (SER) qui 

15 ensuite effectue l'etape de compiler (El, E2 ; E12) . 

6 - Proced6 conforme a l'une quelconque des 
revendications 1 a 5, dans lequel le. moyen de 
traitement de donn£es est une carte a puce (CU, CS) . 

20 

7 - Procede conforme a la revendication 6, dans 
lequel la carte a puce est une carte d'identite 
d'abonne incluse dans un terminal radioteiephonique 
mobile" (TE) . 
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PJ. 



/* Debut d ? un programme JAVA pour carte a puce : reception dans la carte d*un 
message transmis par le serveur */ 
public void process(APDU apdu) // declaration d'une procedure JAVA (carte) 

byte[] buffer, // declaration d*un tableau de travail 

buffer = apdu.getBufferO; // buffer prend le message envoye a carte 

if (buffer[lSO.OFFSET_CLA] != MyApplet CLA) // dasse de commande correcte ? 
throw new ISOException( 

ISO.SW CLA NOT SUPPORTED); // sinon il faut declencher une erreur. 

_}_ : : : : 



El 



JAVA -> pseudo-code pour SE Java. 



; » METHOD process compile pour une marchine virtuelle JAVA « 

method public process(Ljavacard/framework/APDU;)V 
limit stack 3 ; nombre de variables de travail 

limit locals 3 ; nombre de variables locales 

.var 0 is this LCIassI ; declaration variable this 

.var 1 is apdu Ljavacard/framework/APDU ; variable apdu 

.var 2 is buffer [B ; variable buffer 



PJC, 



aloadl 

invokevirtual APDU/getBuffer()[B 
astore_2 
aload_2 
iconstO 
baload 
sipush 204 
ificmpeq Labell 



; chargement sur la pile de Targument apdu 
; appel de la methode getBugffer sur apdu 
; Resultat enregistre dans buffer 
, chargement de la variable buffer 
; chargement de la valeur OFFSET_CLA=0 
; chargement de buffer[OFFSET_CLA] 
; chargement de la valeur MyApplet_CLA=204 
; comparaison des valeurs en sommet de pile 
new javacard/framework/ISOException ; creation d'une instance ^exception 
dup ; duplication du sommet de pile 

sipush 28 1 60 ; chargement valeur ^initialisation « SW_CLA_NOT_SUPPORTED 
invokespecial javacard/framework/ISOException/<init>(S)V ; initialiser 
athrow ; declencher Pexception 

Labell: 

Return ; fin de la methode 

.end method 



E2^ 



Conversion pseudo-code -> LI 



portion de programme LI desassemble 

. arg l,{apdu : JAVA APDU) ; un seul argument attendu : apdu 
Jcl 1, {buffer : JavaByteArray } ; une variable locale : buffer 



PJLL 



; une variable temporaire (tmpO) 
3 constantes : cst0=0,cstl=204,cst2=28160 
; 'buffer 1 prend le buffer de Tapdu 'apdu*. 
; charger la valeur de la case OFFSET CLA de buffer 
; compare Tegalite de buffer[OFFSET_CLA] et 204 
; s'ils sont 6gaux, saut a Labell 
tmpO <- JavaException create cst2 ; creer une exception initialisee a 28160 
void <- JavaException throw tmpO ; Declencher l'exception creee. 
Labell: 
return 



tmp 1 

est 1,(0,204,28160} 
buffer <- apdu getBuffer 
tmpO <- buffer get At cstO 
tmpO <- tmpO != estl 
jumpif tmpO,Labell 
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FIG. 7 



#include <ISOCard.h> /* librairie de developpement pour carte 
#define MYCARD APPLY OxCC 

/* Debut d'un programme C pour carte a puce : reception dans la carte d'un message 
transmis par le serveur */ 

void main(apdu *apdu) /* declaration d"une procedure C (carte) 
{ 

unsigned char *buffer ; /* declaration d'un tableau de travail 
buffer = getApdu(apdu) ; /* 

if(buffer[ISO J)FFSET_CLA] != MYCARD APPLY) /* classe de commande correcte ? 

CardExit(SW^CLA_NOT_SUPPORTED) ; 
Return ; 

} 



E1+E2, ouE12 



Compilation classique C -> LI 



; portion de programme LI disassemble 
arg 1 ,(apdu ; ISOCARD APDUI ; un seul argument attendu : apdu 
Jell , { buffer : UChar Array } ; une variable locale : buffer 

.tmp 1 ; une variable temporaire (tmpO) 

est 1 , { 0,204,28 1 60} ; 3 constantes : cst0=0,cstl=204,cst2=28 1 60 

buffer <- apdu getBuffer ; 'buffer* prend le buffer de Papdu 'apdu'. 
TmpO <- buffer getAt cstO ; charger la valeur de la case OFFSET_CLA de buffer 
tmpO <- tmpO != cstl ; compare I'egalite de buffer[OFFSET_CLA] et 204 
jumpif tmp0,Labell ; s'ils sont egaux, saut a Labell 

void <- System CardExit cst2 ; Declencher I'exception creee. 

Label!: 
return 
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FIG. 8 



PLI^ 

; portion de programme LI 
; disassemble 
lcl 0 
.tmp 1 
est 1,{0} 



tmpO 
void 
return 



<- cstO asls 

<- test toByteArray i 

<- out apduReponse tmpO 



PAD 



E3 

Adaptation 
dansCU 



; portion de code SEU 
; disassemble 
.sstack 0 
.vstack 1 
.lest 1,{0} 

cload cstO 
sstore i 

sload i 

jsm test\toByteArray 

dload out 

jvm apduResponse 
ret 



FIG. 9 



OPJ 



OPLIa 



portion de programme JAVA disassemble 
limit stack 2 
limit locals 0 

new array byte 
iconst_3 
iconstj) 
bastore 



Conversion pseudo-code -> LI 



W 

; portion de programme LI disassemble 
lcl 0 

3 

2,{3,0} 



.tap 
.est 



tmpO <- ByteArraynew 

tmpl <- tmpOgetSize 

tmpl <- cstO <= tmpl 

jumpif tmpl^ArraylsOK 

void <- Exception throws javaOutOffiound 

ArraylsGK: 

void <- tmpO putByteAt cst0,cstl 
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FIG. 10 



OPJ 



OPLIb 



portion de programme JAVA disassemble 
limit stack 2 
limit locals 0 

new array byte 
iconst_3 
iconst_0 
bastore 



j Conversion pseudo-code -> LI adaptable 



; portion de programme LI disassemble 

lcl 0 

.tap 3 

.est 2,(3,0} 



ByteArTay new 
<- tmpO JavaGetByte cst0,cstl 



tmpO < 
tmpl 

; (with) 

; ByteArray/JavaGetByte : 

tmpl <- tmpO get Size 

tmpl <- cstO <= tmpl 

jumpif tmpl,ArrayIsOK 

void <- Exception throws javaOutOfBound 

AxraylsOK: 

void <- tmpO putByteAt cst0,cstl 



PLId 



FIG. 11 



V 



.arg 
lcl 



; portion de programme LI 
desassemble 

Uapdu : ISOCARD_APDU} 
1, (buffer : UCharArray } 
.tap 1 (tmpO) 
.est 1,(0,204,28160) 
buffer <- buffer getAt cstO 
tmpO <- buffer getAt cstO 
tmpO <- tmpO != cstl 
Jumpif tmpOJLabell 
void <- System CardExit cst2 creee. 
Labell: 
return 



7 



E3 

Adaptation 
dans CS 



PADd 



-portion de code Natif (ARM7TDI) 
; desassemble 

; rO = this ; rl = apdu 
; r2 = buffer ; r3 = tmpO 

movrl,rO 

jsr getApdu ; apdu getbuffer 
ldr r3 > [r2,#0] 
cmp r2,#204 
bne labell 



pop rO 
fdr rO,c 



__ _J,cst3[PC] 
jmp cardExit 

labell : 

cst3 : dl #28160 



REPUBLIQUE FRANQAISE 



INST1TUT NATIONAL 
dela 

PROPRIETE INDUSTRIELLE 



RAPPORT DE RECHERCHE 

PREUMINAIRE 

etaWi sur la base des demieres revindications 
deposees avant le commencement de la recherche 



2794543 



N~ <r emegHtrement 
national 



FA 578850 
FR 9907239 



Categorie 



DOCUMENTS CONSIDERES COMME PERTINENTS 



Citation do document avec indication, en cas de besoin, 
des parties pertinentes 



Revendcaiora 
concents 
de ta demandt 
exarrinte 



BERTH F0LLI0T, IAN PIUHARTA, FABIO 
RICCARDI: "Virtual Virtual Machines" 
PROCEEDINGS OF THE 4TH CABERNET RADICAL 
WORKSHOP, inline! 

17 - 20 septembre 1997, XP002135231 
Rethimnon, Crete 
Retrieved from the Internet: 
<URL : http : //www-sor . i nr i a . f r/cg 1 -b i n/go?ur 
l=ftp://ftp. inria.fr/INRIA/Projects/SOR/pa 
pers/1997/VVM_radical97.ps.gz> 
'retrieved on 2000-04-10! 

* le document en entier * 

BERTH F0LLI0T, IAN PIUMARTA, FABIO 
RICCARDI: "A Dynamically Configurable, 
Multi-Language Execution Platform" 
SIG0PS'98 WORKSHOP, 'Online! 1998, 
XP002135232 

Retrieved from the Internet: 
<URL : http : //www-sor . i nr i a . f r/cgi -b i n/go?ur 
l=ftp: //ftp . i nr 1 a . f r/I NR I A/Pro ject s/SOR/pa 
per s/l998/DCMEP_s1 gops98 . ps . gz> 

* retrieved on 2000-04-10! 

* le document en entier * 

DAVID MAY: "VIRTUAL BINARY EASES PROGRAM 

REC0MPILATI0N" 

NEW ELECTRONICS, 

vol. 26, no. 7, juillet 1993 (1993-07), 
page 23 XP000384613 

INTERNATIONAL THOMSON PUBLISHING, LONDON, 
GB 

ISSN: 0047-9624 

* le document en entier * 



1.3,5,6 



1,3,5,6 



DOMAINES TECHNIQUES 
RECHERCHES <lm\CL.7) 



G06F 



10 avril 2000 



Wiltink, J 



CATEGORIC DES DOCUMENTS CITES 

X : particuJierement pertinent a M seul 

Y : particufierernent pertinent en comtrinaison avecun 

autre document de la meme calegorie 
A : pertinent a rencontre d au molns une revencfication 

ou arriere-plan technotoglque general 
O : divulgation non-ecrte 

P : document intercalate 



T : theone ou prtndpe a ta base de finventlon 

E : document de brevet benefctant tfune date anterieure 

a la date de depot et qui n'a ete pubSequ*a cette date 

de depot ou qu*a une date posterieure. 
D : cite dans la demande 
L : cite pour cf autre 3 raisons 

& : membre de ta meme famflte, document correspondant 



page 1 de 2 



REPUBLIQUE FRANQAISE 



INST1TUT NATIONAL 
de la 

PROPRIETE INDUSTRIELLE 



RAPPORT DE RECHERCHE 

PRELIMINAIRE 

etaWi sur la base des dernieres revencfications " 
deposees avant le commencement de la recherche 



2794543 



N" d*enregl$tremenl 



FA 578850 
FR 9907239 



Categorie 



DOCUMENTS CONSIDERES COMME PERTINENTS 



Citation du document avec indication, en cas do besom, 
das parties pertinentes 



<J» ta dcfnarxto 



JEAN-JACQUES VANDEWALLE , CRIC VfTILLARD: 
"Developing Smart Card-Based Application 
using Java Card" 

PROCEEDINGS OF THE THIRD SMART CARD 
RESEARCH AND ADVANCED APPLICATION 
CONFERENCE, (CARDIS'98), LOUVAIN-LA-NEUVE, 
BELGIUM, 'Online! aoOt 1998 (1998-08), 
XP002135233 

Louva1n-la-Neuve, Belgium 

Retrieved from the Internet: 

<URL : http : //www . gemplus . f r/smart/r_d/publ i 

cations/download/card1s/cardis0998-javacar 

d-paper.pdf> 'retrieved on 2000-04-10! 

* abrege * 

* page 4, ligne 1 - page 10, ligne 6 * 

CARINE BAILLARGUET: "Support 
duplications sur une systeme 
d'exploitation adaptatif et special isable" 
RAPPORT DE STAGE DE DEA, 'Online! 
septembre 1998 (1998-09), XP002135234 
Unlversite Pierre & Marie Curie, Paris, FR 
Retrieved from the Internet: 
<URL : http : //www-s or . 1 nr 1 a . f r/ 1 ba 1 1 1 arg/dqc 
s/mvv-rs.ps.g2> 'retrieved on 2000-04-10! 

* abrege * 

* page 1 * 

* page 6 - page 12 * 

* page 16 - page 19 * 

* page 45 * 



6,7 



1,3,5,6 



DOMAINES TECHNIQUES 
RECHERCHES (lnl.CL.7) 



Oat* <fach«v»m»r« d» t» t***tch» 

10 avrll 2000 



Wiltink, J 



CATEGORIE DES DOCUMENTS CITES 



X : parfcufidrement pertinent a tul soul 

Y : pa/ticufterement pertinent an combfnatecn aveeun 

autre document de ta meme categorie 
A : pertinent a f encontia tfau molns una revend5catk>n 

ou arrlere-plan locrmologtquo general 
O : divulgation non-ecrite 

P : document Intercalate 



T I theorte ou prtntipe a ta base de (Invention 

E : document de brevet beneficiant dune date anterieure 

a la date de depot et qui n'a eta pubSoqua certe date 

de depot ou qu*a une date posterieure. 
O ' cite dans la demande 
L : cite pour d*autres ratsons 

& : membra de ta memo t ami Be. document correspondant 



page 2 de 2 



